fix(desktop): enforce owner-only access in internal builds - #4053

Commenting on Wes Billman's behalf after a release-safety review of 16b66e5c916a68e79a7ee6b8e2be21126591c56d.

I found two blockers before this is safe to merge for an internal release:

1. Existing provider deployments are not remediated. The owner-only projection is applied when Desktop constructs a provider deploy payload (desktop/src-tauri/src/commands/agents_deploy.rs), and that payload is sent only through an explicit provider deploy/start path (desktop/src-tauri/src/commands/agents.rs). Installing a marked Desktop build does not redeploy an agent whose backend_agent_id already exists; provider status deliberately survives Desktop restarts. Such an agent can therefore retain its previous anyone/allowlist policy while the upgraded UI reports and locks the setting to “Only me.”

   Please either add a reliable reconciliation/migration for existing provider deployments, or make enforcement state explicit and gate release on inventory plus successful redeployment. The UI must not claim the effective policy changed until the remote deployment has accepted it. Add coverage for the upgrade case: an already-deployed provider agent with wider stored/effective access receives the owner-only policy during rollout.

2. The enforced principal set is broader than the stated contract. RespondTo::OwnerOnly in crates/buzz-acp/src/lib.rs admits the human owner and NIP-OA-verified same-owner sibling agents. This PR intentionally relies on that behavior for Welcome teammates. That may be the desired authorization model, but it conflicts with “answer only their owner” and UI copy that says only the user can send instructions.

   Please obtain an explicit product/security decision that owner ∪ verified same-owner agents is the intended internal boundary and update the PR/UI language accordingly, or change the authorization behavior to satisfy literal human-owner-only access. This is an authorization-set decision, not merely copy polish.

The local spawn clamp, independent BUZZ_ACP_ALLOWED_RESPOND_TO=owner-only guard, provider payload projection, and compile-time marker wiring otherwise look sound in the reviewed diff. Before merge, this branch should also be updated from main and revalidated after the blockers are resolved.

@wesbillman those make sense but don't seem like they should be blocking. Do you agree?

Additional blocker found in the independent security pass, commenting on Wes Billman's behalf:

3. The baked build environment can overwrite both enforcement gates after Desktop sets them. BUZZ_BUILD_AGENT_ENV accepts arbitrary keys at build time (desktop/src-tauri/build.rs:42-71), and baked_build_env() returns those entries without reserved-key filtering (desktop/src-tauri/src/managed_agents/agent_env.rs:22-61). They enter the effective descriptor as its baked floor (desktop/src-tauri/src/managed_agents/readiness.rs:226-270). Local spawn sets BUZZ_ACP_RESPOND_TO=owner-only and BUZZ_ACP_ALLOWED_RESPOND_TO=owner-only first (desktop/src-tauri/src/managed_agents/runtime.rs:754-764), then writes every descriptor.env entry last (runtime.rs:803-813). An internal build packaged with both keys set to anyone therefore produces an agent that answers anyone.

The expanded RESERVED_ENV_KEYS protects user/persona/definition input, but not this baked tier. Reject reserved keys in BUZZ_BUILD_AGENT_ENV at build time or filter them before they reach descriptor.env, and add a test proving baked collisions cannot override either access gate. This is a direct bypass of the boundary the PR intends to make invariant.

One additional upgrade-path bug from Mongo's independent lifecycle review, confirmed at 99685b52b:

4. Welcome teammate remediation never converges in owner-only builds. The new expected-state predicate requires owner-only with an empty allowlist in a marked build, but the remediation branch still unconditionally writes allowlist:[lead] (desktop/src/features/onboarding/welcomeGuide.ts:349-359). A pre-existing install whose teammates carry the old allowlist state therefore fails the predicate, writes the same invalid-for-this-build state again, and repeats on later provisioning passes. Running teammates also continue satisfying welcomeTeammateNeedsRestart (welcomeKickoff.ts:360-373), causing redundant restarts.

This is not another authorization bypass—the Rust boundary still clamps effective access—but it is a real upgrade regression and contradicts the PR's goal of avoiding unnecessary Welcome restarts. Make the remediation target owner-only/empty when the build policy is active, and test the full remediation write for a pre-existing allowlisted teammate rather than only the predicate's happy path.